Terraform StacksのOrchestration rulesを試してみた
2024.11.18Terraform StacksのDeploymentsを管理できるOrchestration rulesについて試してみました。
Terraform Stacksとは
Terraform Stacksは、複数環境・複数リージョン(複数Statefile)を使った構成を効率的に管理できる機能です。
本記事執筆時点(2024/11)では、パブリックベータです。
Orchestration rulesとは
Terraform Stacksに、Orchestration rulesという機能があります。
この機能を使うと、Deploymentsを管理するルールを作成できます。
現時点では以下の2種類のルールを作ることができます。
| ルール | 実行タイミング | 用途 |
|---|---|---|
| auto_approve | Plan作成時 | 手動承認なしで、Planを適用したい |
| replan | Apply時(Plan適用時) | Plan適用時に別のPlanを実行したい |
例えば、本番環境のDeploymentsは手動承認必須・その他環境は自動承認といったルールを作成できます。
Orchestration rulesの作り方
*.tfdeploy.hclファイルに、orchestrateブロックを使って記述します。
ルールはcheckブロックを使って定義します。
# 本番環境以外の環境を自動承認
orchestrate "auto_approve" "no_prod" {
check {
condition = context.plan.deployment != deployment.prod
reason = "Not automatically approved prod."
}
}
context変数に含まれるフィールド等は以下で確認できます。
ルールを作ってみる
開発環境のPlanを自動承認
orchestrate "auto_approve" "dev" {
check {
condition = context.plan.deployment == deployment.dev
reason = "Automatically approved dev."
}
}
分かりやすくていいですが、自動承認の対象環境が増えるとcheckブロックかorchestrateブロックを増やす必要があります。
次に紹介するルールのほうがより実践的です。
ちなみに、auto_approveの適用はPlan結果の「Timeline」上で確認できます。
非本番環境でリソースを削除しないプランを自動承認
「開発環境のPlanを自動承認」の応用版です。
上記の公式ドキュメント内でも紹介されているルールです。
1つ目のcheckブロックでPlanに削除が含まれていないことを、2つ目で非本番環境であることを判定しています。
orchestrate "auto_approve" "safe_plans" {
# Ensure that no resource is removed.
check {
condition = context.plan.changes.remove == 0
reason = "Plan is destroying ${context.plan.changes.remove} resources."
}
# Ensure that the deployment is not your production environment.
check {
condition = context.plan.deployment != deployment.production
reason = "Production plans are not eligible for auto_approve."
}
}
Apply後にPlanを自動で実行
Apply後、確認のためにPlanを再実行することがあると思います。
replanリソースを使って、以下のように定義できます。
orchestrate "replan" "verification" {
check {
condition = context.operation == "apply"
reason = "Post-apply verification replan"
}
}
replanルールによるPlanかは、Planの画面上から確認できます。
変更なしでも、手動承認ありだと「waiting」のステータスになるため、変更無しの場合は自動承認する「auto_approve」のルールと組み合わせたほうが良いかもしれません。(手動承認してもOK)
補足:
Deferred Changeで遅延させたPlanを再実行してみようと思いましたが、Plan適用時に遅延したPlanが実行されたので不要でした。
おわりに
Orchestration rulesについてでした。
Workspacesで環境ごとにApplyトリガーの設定を行う場合、GUIまたはtfe providerを使う必要があります。
Terraform Stacksでは、*.tfdeploy.hclに書くだけののため、設定が簡単でした。
以上、AWS事業本部の佐藤(@chari7311)でした。
